System and method for automatic software code generation

ABSTRACT

A system including a code generation engine automatically generating software code for a handler function using one of handler function information and parameter information. A method including receiving parameter information via a graphical user interface, receiving handler function information via a graphical user interface and automatically generating handler function code using the parameter information and handler function information.

INCORPORATION BY REFERENCE

[0001] This application claims the benefit of U.S. Provisional PatentApplication 60/186,560 filed on Mar. 2, 2000 and entitled “Method andSystem for Modular Software Architecture for Peer-to-Peer Management ofNetwork Devices” and is expressly incorporated herein, in its entirety,by reference. Additionally, the application entitled “System and Methodfor a Command Structure Representation” to the same inventors named inthis application and filed on an even date herewith and the applicationentitled “System and Method for Common Code Generation” to the namedinventors David Reyna and Shawn-lin Dzeng, filed on an even dateherewith, both of which are assigned to the Assignee of the presentapplication, are expressly incorporated herein, in their entirety, byreference.

BACKGROUND INFORMATION

[0002] The command line interface (sometimes also referred to as acommand shell or simply a “shell”) is a common interface for computeroperating systems (e.g., DOS, UNIX, etc.). A user enters commands on thecommand line one line after another and the operating system executesthe commands in the order of entry. The operating system does notdistinguish a command from a program. Commands and programs are runafter the user has typed the name of the command or program and pressedthe “Enter” key. The pressing of the “Enter” key signals to the systemthat the user has finished entering the text and it may begin runningthe command. For example, the user may type “Command0” in the commandline interface and then press the “Enter” key. In this case, thepressing of the “Enter” key signals to the operating system that itshould execute the “Command0” command.

[0003] In the case of the operating systems described above (e.g., DOS,UNIX), there is a standard set of commands included with the operatingsystem. However, software developers may desire to add additionalcommands to this standard set while other software developers may bedeveloping completely new operating systems which do not have anycommands. These new operating systems may be, for example, for embeddeddevices (i.e., any device that may be networked with another electronicdevice). Examples of embedded devices include wireless telephones, PDAs,home appliances, office products, networking equipment, factoryautomation products, automotive components, security devices, etc. Theseoperating system developers generally use a software development suiteto build the new operating system including a command line interface andaccompanying commands.

[0004] Despite the importance of the command line interface, it is oftenone of the most poorly engineered aspects of device architectures.Commands are often designed and implemented in a quick and dirty fashionmerely to test a newly developed feature. This development scheme doesnot lend itself to an architecture that is both efficient at run-timeand easy to modify and extend.

SUMMARY OF THE INVENTION

[0005] The present invention is directed to a system including a codegeneration engine automatically generating software code for a handlerfunction using one of handler function information and parameterinformation. Furthermore, the present invention is directed to a methodincluding receiving parameter information via a graphical userinterface, receiving handler function information via a graphical userinterface and automatically generating handler function code using theparameter information and handler function information.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006]FIG. 1 shows an exemplary command tree according to the presentinvention;

[0007]FIG. 2 shows an exemplary architecture having functions forcreating and editing command nodes according to the present invention;

[0008]FIG. 3 shows an exemplary command tree branch having command nodesaccording to the present invention;

[0009]FIG. 4 shows an exemplary graphical user interface for the commandtree manifest according to the present invention;

[0010]FIG. 5 shows an exemplary command tree representation of thecommands shown on the graphical user interface of FIG. 4;

[0011]FIG. 6 shows an exemplary process for adding a command node to acommand tree according to the present invention;

[0012]FIG. 7 shows an exemplary graphical user interface for the commandnode editor according to the present invention;

[0013]FIG. 8 shows an exemplary graphical user interface for theparameter editor according to the present invention;

[0014]FIG. 9 shows an exemplary graphical user interface for the handlereditor according to the present invention;

[0015]FIG. 10 shows an alternative exemplary graphical user interfacefor the functions according to the present invention;

[0016]FIG. 11 shows an exemplary graphical user interface for thehandler code generation engine according to the present invention.

DETAILED DESCRIPTION

[0017] The present invention may be further understood with reference tothe following description of preferred exemplary embodiments and therelated appended drawings, wherein like elements are provided with thesame reference numerals. Throughout this specification the terms commandand command node may be used interchangeably. Additionally, theexemplary embodiments of the present invention will be discussed withreference to embedded devices and the accompanying operating systems.However, those skilled in the art will understand that the presentinvention is not limited to embedded systems, and may be used with anyoperating system that supports a Command Line Interface (“CLI”).Additionally, the term developer is generally used throughout thisdescription to describe the individual responsible for developing theoperating system (e.g., adding new commands, editing existing commands,etc.) The term user is generally used to describe the individual thatmay be using the operating system (e.g., entering commands in the CLIfor the operating system to execute). However, the terms may be usedinterchangeably throughout this description. For example, the term usermay also describe the individual responsible for developing theoperating system.

[0018]FIG. 1 shows an exemplary command data structure, such asexemplary command tree 1 having command nodes 10-60. Command tree 1 is ahierarchical representation of the commands available to the user of theoperating system. All of the command nodes lead back to root node 10where the traversing of the structure begins each time a user enters acommand in the CLI. In exemplary command tree 1, root node 10 has threechild command nodes, show node 20, set node 30 and get node 40.Additionally, show node 20 has two child command nodes, ipx node 50 andip node 60. When a user enters a command on the CLI, the operatingsystem parses the command and determines the appropriate action to take.For example, if the user types in the command “show ip” and presses the“Enter” key, the operating system will first parse the command into itsconstituent parts (e.g., “show” and “ip”). The operating system willthen traverse command tree 1 until it reaches the appropriate leaf ofthe tree. In this example, the operating system will first reach shownode 20 and then ip node 60. A handler function, which will be describedin greater detail below, associated with show node 20 and ip node 60will be called and the appropriate output will be sent back to the user.Those skilled in the art will understand that command tree 1 may havenumerous command nodes that are nested to multiple levels. Exemplarycommand tree 1 has three levels of nesting: the first level containsroot node 10; the second level contains show node 20, set node 30, andget node 40; and the third level contains ipx node 50 and ip node 60.However, it may be possible to go to much deeper levels of nesting byadding additional command nodes that are children, grandchildren, etc.to the existing command nodes. For example, adding child command nodesand grandchild command nodes to ip node 60 would result in nesting ofcommand tree 1 to a fifth level. This may result in multiple branches oncommand tree 1, but all these branches will still start at root node 10.

[0019] Command nodes 10-60 may be stored in a database which may includeinformation on a particular command node 10-60 such as a keyword orname, a help string, a prompt string, the access level, “no form”capabilities, the number of child nodes, pointers to the child nodes, anumber of parameters associated with the command node, pointers to theparameter descriptions, the number of handler functions, pointers to thehandler functions, etc. Thus, when a developer is defining a new commandthere may be a multitude of pieces of information the developer mayinclude about the new command in order for that command to be properlyinserted within the command structure. The exemplary embodiment of thepresent invention allows the developer to quickly create CLI commands bycreating the structure of command nodes. Each command node may, in turn,be edited to add parameters and handler functions. The exemplaryembodiment of the present invention also allows for the automaticgeneration of software code for the handler functions and provides forthe modification of the generated code.

[0020]FIG. 2 shows exemplary architecture 100 having functions 110-140for creating and editing command nodes. Command structure manifest 110enables a developer to visually manipulate the command structure byadding and deleting command nodes at any level. Command node editor 120allows the developer to create and edit command nodes including theability to add parameters and handler functions, modify help strings andset security levels. Handler editor 130 allows the developer to createand edit skeletons for handler functions which may be associated withcommand nodes including the association of parameters with particularhandler functions. Handler code generation engine 135 accepts the dataentered by the developer about a handler function and converts it to asource file containing the skeletal versions for the handler function.Parameter editor 140 allows the developer to edit parameters for commandnodes including the name and variable type of the parameter. Commandstructure generation engine 145 accepts the data entered by thedeveloper in the other functions and converts it into a file describingthe full command set specified by the developer. The file may containthe static initialized command node structures, the static initializedparameter definitions and the static initialized handler definitions.Operation of each of functions 110-145 will be described in greaterdetail below.

[0021]FIG. 3 shows exemplary command tree branch 150 having commandnodes 155-180. Those of skill in the art will understand that exemplarycommand tree branch 150 may be part of a larger command structure.Exemplary command tree branch 150 may correspond to the exemplarycommand:

ifconfig eth0 address 1.2.3.4 netmask 255.0.0.0 broadcast 1.255.255.255up

[0022] In this case, the exemplary command would be parsed in thefollowing manner: ifconfig node 160, address node 165, netmask node 170,broadcast node 175 and up node 180. Each of command nodes 155-180 haseither an associated handler function or an associated parameter.Ifconfig node 160 has an associated parameter named interface, which inthe exemplary command above is “eth0”. “eth0” may refer, for example, toan Ethernet connection as the type of interface typed in combinationwith this command. Address node 165 has an associated parameter named IPaddress, which in the exemplary command above is “1.2.3.4.” Netmask node170 also has an associated parameter named IP address, which in theexemplary command above is “255.0.0.0.” Broadcast node 175 also has anassociated parameter named IP address, which in the exemplary commandabove is “1.255.255.255.” When each of command nodes 165-175 is invoked,the user inputs an IP address as the parameter for these commands. Upnode 180 has an associated handler function named “config.” The handlerfunction has associated software code. Executing this software codecauses the operating system to carry out the particular command typed bythe user in the CLI. Thus, when the user types in the exemplary commanddescribed above and presses the “Enter” key, the operating system parsesthe command into its constituent parts and traverses command tree branch150. When the operating system reaches up node 180, the operating systemretrieves the appropriate handler function (e.g., “config”) and executesthe software code associated with the handler function using theparameters entered by the user, resulting in the complete execution ofthe command.

[0023]FIG. 4 shows an exemplary command graphical user interface (“GUI”)200 for command structure manifest 110 described with respect to FIG. 2.Command structure manifest 110 enables a developer to visuallymanipulate the command structure by adding and deleting command nodes atany level. The process of adding and deleting command nodes will bedescribed in greater detail below. The following is a description of GUI200 which shows commands that have already been created for a particularoperating system. GUI 200 shows these command nodes in a hierarchicalarrangement. The command structure has root node 205 which has sevenchildren command nodes: command0 node 210, command0 node 220, command2node 230, command3 node 240, command4 node 250, set node 260, and shownode 270. GUI 200 indicates that these seven command nodes 210-270 arechildren of root node 205 by showing them below and on the first levelof offset from root node 205. Referring to set node 260, GUI 200indicates that there are three child command nodes (i.e., ip node 261,struct node 262 and sysname node 263) for set node 260. Once again, GUI200 indicates that command nodes 261-263 are children of set node 260 byshowing them below and on the first level of offset from set node 260.Additionally, GUT 200 also shows parameters and handler functionsassociated with each command node. For example, command3 node 240 hastwo associated parameters, unnamed1 parameter 241 and unnamed2 parameter242 and handler function VD_Command3Handler 243. It should be clear thatparameters 241-242 and handler function 243 are associated with command3node 240 because they are situated directly underneath and in the firstlevel of offset from command3 node 240. GUI 200 also distinguishesbetween command nodes, parameters and handler functions by showing, atthe start of the name for each entry, an icon that is unique for thatentries classification—i.e., command node, parameter or handlerfunction. For example, command3 node 240 has a different icon thanunnamed1 parameter 241, while VD_Command3Handler 243 is preceded by athird icon. However, command0 node 210 has the same icon as command3node 240, indicating they are both command nodes.

[0024]FIG. 5 shows an exemplary command tree representation 280 of thecommands shown on GUI 200 of FIG. 4. As described above, root node 205is the command node from which the other command nodes branch. The sevenchild command nodes 210-270 are shown directly under and connected toroot node 205. Child command nodes 261-263 of set node 260 are showndirectly under and connected to set node 260. Those command nodes whichhave associated parameters and/or handler functions are shown asincluded in the command node. For example, command3 node 240 is showncontaining the two associated parameters, unnamed1 parameter 241 andunnamed2 parameter 242 and handler function VD_Command3Handler 243.

[0025]FIG. 6 shows an exemplary process 300 for adding a command node toa command structure. In step 310, the developer selects the location inthe command structure to insert the new command node. For example,referring back to FIG. 4, if the developer were inserting command0 node210, the developer would highlight root node 205 and click on “+”button201 on GUI 200 or simply double click on root node 205. This selectionindicates that the developer desires to add a command node that is achild of root node 205. Similarly, if the developer were inserting ipnode 261, the developer would highlight set node 260 and click on“+”button 201 on GUI 200 or simply double click on set node 260,indicating the desire to add a command node that is a child of set node260. After the developer has selected the location for the new commandnode, the process continues to step 320 where the developer enters thecommand node editor 120 and provides information about the new commandnode.

[0026]FIG. 7 shows an exemplary GUI 400 for command node editor 120.Those of skill in the art will understand that GUI 400 is only exemplaryand that the GUT for command node editor 120 may include more or lessfields than those described with reference to FIG. 7. The firstinformation that may be provided by the developer about the new commandnode may be the name of the command node which is entered in field 401of GUI 400. The developer may then enter a help string for the newcommand in filed 402 of GUI 400. A help string is a short text message auser may access when using the operating system. For example, forcommand0 node 210, the developer may have entered a help string in field402 as follows: “help string for command0”. Thus, when a user types“help command0” in the CLI, the text message “help string for command0”would appear to the user. Other information about the new command nodethat may be entered via GUI 400 includes an indication as to whether toallow no form handling in field 403 which is the ability to recognizeand handle the negative form of the new command (e.g., no command0), theaccess level required for access to the new command in field 404 (e.g.,“0”indicates that all users may access the command) and the promptstring in field 405. Using the example of the developer adding command0node 210, the developer may fill in “command0” in field 401, the helpstring described above in field 402 and the desired settings in thefields 403-405.

[0027] The current nodes field 406 of GUI 400 describes the family orcommand structure branch to which the new command node belongs. Thisfield is not filled in by the developer, but is automatically filled inbased on the location selected for the new command by the developer instep 310. For example, if GUI 400 of command node editor 120 were openfor command0 node 210, current nodes field 406 would be empty becausecommand0 node 210 is a child of root node 205. However, if GUI 400 ofcommand node editor 120 were open for struct node 262, set node 260would appear in current nodes field 406 indicating that struct node 262is a child of set node 260.

[0028] When the above data is entered into the new command in step 320via GUI 400, the process continues to step 330, where the parameters areentered for the new command. The entering of parameters is alsoaccomplished via GUI 400 by adding the desired parameters to parameterfield 410. Similarly to the addition of a new command, the parametersmaybe added via a GUI associated with parameter editor 140. GUI 400 isshown having no parameters in parameter field 410. However, a developermay add parameters to the new command by clicking on add button 411.Those of skill in the art will understand that a command node is notrequired to have a parameter. Thus, step 330 may be considered anoptional step in that the developer may not elect to add any parametersto the new command. In such a case, parameter field 410 on GUI 400 willremain empty.

[0029]FIG. 8 shows an exemplary GUI 450 for parameter editor 140. Theaction of clicking on add button 411 may bring up GUI 450 which may beused by the developer to add a parameter to the new command. Those ofskill in the art will understand that GUI 450 is only exemplary and thatthe GUI for parameter editor 140 may include more or less fields thanthose described with reference to FIG. 8. GUI 450 may indicate thecommand node with which the parameter is associated (e.g., command3 node240 in the example shown in FIG. 8). The developer may then fill in theinformation for the parameter via GUI 450. No keyword field 451 of GUI450 indicates whether the parameter will have a keyword or name. A nokeyword parameter is an implied type parameter that will remain unnamed.For example, there may be a command “reboot” with a parameter named“timeout”. When a user types “reboot timeout 5” on the CLI, it indicatesthe command of “reboot”, the parameter “timeout” and the value “5” forthe parameter, which causes the device to reboot after the timeoutperiod of 5. However, it is also possible to leave the parameter asunnamed. In this case, the user may enter “reboot 5” on the CLI, whichwill also cause the device to reboot after the timeout period of 5because 5 is an implied timeout parameter. If the parameter is not animplied type (i.e., no keyword field 451 is not checked), the developerwill fill in a name for the parameter in parameter keyword field 452.The developer will also select the type of parameter in parameter typefield 453 (e.g., unsigned long, integer, string, boolean, etc.). Thedeveloper may then also fill in fields 454-461 as appropriate for theparticular parameter that is being added.

[0030] When the parameter is configured to the satisfaction of thedeveloper, the OK button may be clicked taking the developer back to GUI400 of command node editor 120. The newly added parameter will then beshown as a parameter for the new command node in parameter field 410 ofGUI 400. Those of skill in the art will also understand that theparameters for a command node may be edited by pressing edit button 412and may be deleted by pressing delete button 413. Edit button 412 maycause GUI 450 of parameter editor 140 to reappear, whereupon thedeveloper may edit any of fields 451-461. It is also possible for thedeveloper to add multiple parameters to the command node. For example,referring to GUI 200 in FIG. 4, command3 node 240 has two parameters,unnamed1 parameter 241 and unnamed2 parameter 242.

[0031] Referring back to FIG. 6, when the insertion of parameterinformation in step 330 is complete, the process continues to step 340,where the handler functions are entered for the new command. Similar tothe entering of parameters, the entering of handler functions is alsoaccomplished via GUI 400 by adding the desired handler functions tohandler function field 420. The handler functions may be added via a GUIassociated with handler editor 130. GUI 400 is shown as having nohandler functions in handler function field 420, but a developer may addhandler functions to the new command by clicking on add button 421.Those of skill in the art will understand that a command node is notrequired to have a handler function. Thus, step 340 may be considered anoptional step in that the developer may not elect to add any handlerfunctions to the new command. In such a case, handler function field 420on GUI 400 will remain empty. Delete button 413 may cause handlerfunction field 420 to be updated if deleted parameters are associatedwith any handler functions.

[0032]FIG. 9 shows an exemplary GUI 500 for handler editor 130. Theaction of clicking on add button 421 may bring up GUI 500 which may beused by the developer to add a handler function to the new command.Those of skill in the art will understand that GUI 500 is only exemplaryand that the GUI for handler editor 130 may include more or less fieldsthan those described with reference to FIG. 9. GUI 500 may indicate thecommand node with which the handler function is associated (e.g.,command3 node 240 in the example shown in FIG. 9). The developer maythen fill in the information for the handler function via GUI 500. Thedeveloper may fill in the name of the handler function in handler namefield 501 (e.g., VD_Command3Handler). A list of the available parameterswill be shown in available parameter field 502. The list of availableparameters will be those added by the developer in step 330 of thecurrent command node and/or parameters in one of the parent commandnodes of the current command node (i.e., parameters from any commandnode that is at a higher level in the same command structure branch areavailable to the current command node). Thus, any parameter that isadded to a command node, will also be available for any child commandnodes of the command node to which the parameter is added. If theparameter listed in available parameter field 502 is not associated withthe current command node, but rather with a parent command node, thedeveloper will be aware of this because it will be shown named with thecommand node with which it is associated. For example, an exemplarycommand node named command5 may have a parameter unnamed1 and a secondexemplary command node named command5child, which is a child ofcommand5, may have a parameter unnamed 1. GUI 500 of handler editor 130when opened for a handler function of command5child may show the list ofavailable parameters in available parameter field 502 as:

unnamed1

command5=>unnamed1

[0033] This listing of parameters indicates that “unnamed1” isassociated with command5child, while “command5=>unnamed1” is associatedwith command5, but available to command5child because it is a child ofcommand5.

[0034] The developer may select any of the parameters in availableparameter field 502 by highlighting the desired parameter. The developermay then determine whether the parameter will be a required parameter oran optional parameter by pressing required button 504 or optional button505, respectively. When the developer selects a parameter from availableparameter field 502 and presses one of buttons 504 and 505, GUI 500shows the selected parameter in handler parameter field 503. In theexample of FIG. 9, parameter unnamed1 is shown in handler parameterfield 503 as a required parameter, while parameter unnamed2 is shown asan optional parameter. A required parameter is one that is required tobe typed in with the command on the CLI for the operating system toexecute the command. An optional parameter is one that may be typed inwith the command on the CLI, but the operating system may still executethe command without the typed parameter. For example, referring to FIG.4, handler function VD_SetSysNameHandler 265 of command node sysName 263has a required parameter unnamed1. Those of skill in the art willunderstand that it is not necessary to select a parameter for everyhandler function. For example, although available parameter field 502may list multiple parameters available to the handler function, thedeveloper may not desire to associate any parameter with the particularhandler function. In this case, the developer would not select anyparameter from available parameter field 502. GUI 500 also has customhandler code field 510 which includes enable button 511, code view field512, edit handler button 513 and reconcile parameter changes button 514.Custom handler code field 510 will be described in greater detail below.

[0035] When the handler function is configured to the satisfaction ofthe developer, the OK button may be clicked taking the developer back toGUI 400 of command node editor 120. The newly added handler functionwill then be shown as a handler function for the new command node inhandler function field 420 of GUI 400. Those of skill in the art willalso understand that the handler functions for a command node may beedited by pressing edit button 422 or deleted by pressing delete button423. Edit button 422 may cause GUI 500 of handler editor 130 toreappear, whereupon the developer may edit any of fields 501-503. It isalso possible for the developer to add multiple handler functions to thecommand node. In the case of multiple handler functions, the operatingsystem may call the appropriate code for each of the handler functionswhen executing the command.

[0036] Referring back to FIG. 6, when the handler functions are insertedin step 340, the process continues to step 350 where the commandstructure is generated by command structure generation engine 145 usingthe information entered by the developer. Referring to FIG. 7, thedeveloper initiates the generation process by pressing apply button 442on GUI 400 which saves the information entered by the developer andgenerates the file described above. GUI 400 also has close button 441,revert button 443 and help button 444. Those skilled in the art willunderstand that these buttons operate in a standard manner. The commandstructure may be an include file with the following structure: cmdNodemRootChildren[ ] = { { “command0”, kCommand0Help, NULL, 0, FALSE, 0,NULL, 0, NULL, 1, mCommand0Handlers }, { “command1”, kCommand1Help,NULL, 0, FALSE, 0, NULL, 1, mCommand1 Params, 1, mCommand1Handlers }, {“command2”, kCommand2Help, NULL, 0, FALSE, 0, NULL, 1, mCommand2Params,1, mCommand2Handlers }, { “command3”, kCommand3Help, NULL, 0, FALSE, 0,NULL, 2, mCommand3Params, 1, mCommand3Handlers } }; cmdNode mRootCmdNode= { NULL, NULL, NULL, 0, FALSE, 4, mRootChildren, 0, NULL, 0, NULL };

[0037] This code describes the root node (i.e., mRootCmdNode) and fourchild nodes (i.e., command0, command1, command2 and command3). Asdescribed above, each node may have information associated with the nodethat may be defined by the developer. Command structure generationengine 145 takes the information entered by the developer and generatesthe file that may be stored as the command structure. The exemplary codeabove may include the following information: keyword or name, helpstring, mode definition, access level, no form allowed, number ofchildren, pointer to array of children, number of parameters, pointer tothe array of parameters available to the node, number of handlerfunctions attached to the node and a pointer to the array of handlerfunctions. For example, root node mRootCmdNode is defined at the bottomof the code. The root node has no keyword or name (NULL), no help string(NULL), no mode definition (NULL), an access level of“0”, the no form isnot allowed (FALSE), the number of children is “4”, the pointer to thearray of children is “mRootChildren”, no associated parameters (0), nopointer to an array of parameters (NULL), no handler functions (0), andno pointer an array of handler functions (NULL).

[0038] The upper portion of the code describes the children of the rootnode. As described above, in this example, the root node has fourchildren and a pointer to the array of command nodes mRootChildren. Tocarry through with the example, the code with respect to command3 willbe described. This node has a name (command3), a help string variable(kCommand3Help), no mode definition (NULL), an access level of “0”, theno form is not allowed (FALSE), no children (0), no pointer to an arrayof children (NULL), two associated parameters (2), the pointer to thearray of parameters is “mCommand3Params, one handler function (1), andthe pointer to the array of handler functions is “mCommand3Handlers.” Inthe case of the help string variable the variable may be initialized ina portion of the code not shown to the string entered by the developer(e.g., #define kCommand3Help “\ help string for command 3 \”). Those ofskill in the art will understand that the code for the remainder of thechild commands is similar to that of command3.

[0039] The process then continues to step 360 where the handler functiondefinitions and parameter definitions are generated by command structuregeneration engine 145. Similar to the command structure, commandstructure generation engine 145 takes the information input by thedeveloper and generates a file containing the information for thehandler functions and parameters. This file may be the same file as thatgenerated for the command structure or it may be separate files. Anexemplary file generated for the parameter definitions may be asfollows: paramDefn mCommand3Params[ ] = { { “param1”, kstring,0x00000001, 1, 0, NULL }, { “param2”, kstring, 0x00000002, 2, 0, NULL }};

[0040] This code describes an exemplary parameter definition arraymCommand3Params for command3. As described above, command3 has twoparameters and a pointer to the array mCommand3Params for theparameters. As described above, the developer may have enteredinformation for each of these parameters in, for example, GUI 450.Command structure generation engine 145 takes the information entered bythe developer and generates the parameter definition file. The exemplarycode above may include the following information: keyword or name, datatype (e.g., integer, boolean, etc.), a unique bitmask identifier,relative position to a given sequence of parameters, flags, and apointer to a structure that may have more detailed information on theparameter. For example, referring to the exemplary line of code forparam1, the name of the parameter is param1, the data type is a kstring,the unique bitmask identifier is 0×00000001, its relative position isone compared to the other parameters (e.g., param2), there are no flagsset (0) and there is no pointer to another structure (NULL). Those ofskill in the art will understand that the code for param2 is similar tothat of param1.

[0041] An exemplary file generated for the handler function definitionsmay be as follows: handlerDefn mCommand3Handlers[ ] = { { 0, 0x00000001,0x00000002 VD_Command3Handler } };

[0042] This code describes an exemplary handler function definitionarray mCommand3Handlers for command3. As described above, command3 hasone handler function and a pointer to the array mCommand3Handlers forthe one handler function. As described above, the developer may haveentered information for the handler function in, for example, GUI 500.Command structure generation engine 145 takes the information entered bythe developer and generates the handler function definition file. Theexemplary code above may include the following information: the type ofcommand (e.g., can this command handle “No” forms), the bitmask ofrequired parameters, the bitmask of optional parameters and the actualhandler function associated with the definition. For example, referringto the exemplary code for the command3 handler function, the commandtype is “0” meaning that it cannot handle the “No” form, the bitmask ofparam1 is identified as a required parameter (0×00000001), the bitmaskof param2 is identified as an optional parameter (0×0000002) and theactual handler function is identified as VD_Command3Handler. The actualhandler function will be described in greater detail below.

[0043] The process then continues to step 370 where the handler functioncode is generated by handler code generation engine 135. As describedabove, the handler function has associated software code. Executing thissoftware code causes the operating system to carry out the particularcommand typed by the user in the CLI. Handler code generation engine 135automatically generates this software code using the information enteredby the developer and the parameter and handler function definitionsgenerated by command structure generation engine 145. The code generatedby handler code generation engine 135 may be as follows: extern RLSTATUSVD_Command3Handler (void *pCliEnv, struct paramlist *pparams, shyte*pAuxBuf) { RLSTATUS status = OK; sbyte *pVal1; paramDescr*pParamDescr1; sbyte *pVal2 = NULL paramDescr *pParamDescr2; /* getrequired parameter */ RCC_DB_RetrieveParam (pParams, “param1”,0×00000001, &pParamDescr1); pVal1 = (sbyte*) (pParamDescr1−> pValue); /*get optional parameter */ status = RCC_DB_RetrieveParam (pParams,“param2”, 0×00000002,       &pParamDescr2); if ( OK == status) { pVal2(sbyte*) (pParamDescr2−> pValue); } /* TO DO: Add your handler code here*/ return status; }

[0044] Those skilled in the art will understand that this exemplarysoftware code carries through with the example started above and may beexemplary code generated by handler code generation engine 135 forhandler function VD_Command3Handler for command3. This function is givena pointer to a paramList structure which is a listing of all theparameters received by the command upon being called and paramDescrstructure. Since both the paramList and paramDescr structures may changeduring the course of development, an abstract manner of getting thevalues associated with a parameter is provided. This manner is providedby the function RCC_DB_RetrieveParam() function. To access the value ina given parameter using this function, all that is needed is theparamList that the handler receives, a set of parameter identifiers(e.g., keyword and/or bitmask identifier) and the address of a pointerto a paramDescr structure. If the RCC_DB_RetrieveParam() function canfind the parameter based on the keyword or bitmask identifier, then itinitializes the parameter description to point to the relevant parameterwithin the parameter list. Referring to the portion of the codeassociated with the optional parameter (i.e., the portion of the codeunder the comment line “/* get optional parameter */”), the parameter isidentified by both keyword (param2) and bitmask (0×00000002). If theoptional parameter was entered in the CLI by the user, the parameterdescription (pParamDescr2) is initialized to point to the relevantparameter within the parameter list (pValue). In the case of thegenerated code for a required parameter (i.e., the portion of the codeunder the comment line “/* get required parameter */”), the generatedcode does not need to contain error checking on whether or not itreceived the parameter because the handler function would not be calledunless the parameter was there. This code may be viewed as it is beinggenerated in code view field 512 of GUI 500 as parameters are beingadded to the handler function.

[0045] Once the value is set for a parameter, the handler function mayuse the value in any manner that the developer desires. For example, thedeveloper may desire that the parameter value is displayed to the user.To carry out this function, the developer may add additional lines ofcode to the handler function. Handler code generation engine 135provides for this by indicating in the generated code where thedeveloper may insert additional code to accomplish functions desired bythe developer. For example, the exemplary generated code described aboveincludes a comment line “/* TO DO: Add your handler code here */”indicating where in the automatically generated code, a developer mayenter additional code. This portion of code may be generated in responseto the developers checking of enable button 511 of GUI 500. By checkingenable button 511, the developer indicates that he may desire to addcustom handler function code to the automatic code generated by handlercode generation engine 135. When the developer desires to add thiscustom code to the handler function, he may press edit handler button513 and a new GUI containing the code may appear on the display on whichthe developer may edit the automatically generated code.

[0046]FIG. 11 shows an exemplary GUI 600 for the handler code generationengine 135. GUI 600 displays the code generated by handler codegeneration engine 135 so that the developer may view, review and acceptthe automatically generated code. In the example of FIG. 11, GUI 600 isdisplaying the same automatically generated code for the handlerfunction VD_Command3Handler of command3 as was discussed in detailabove. The developer may also use GUI 600 to add any additional lines ofcode the developer desires to add to the handler function.

[0047] Those skilled in the art will understand that it may also bepossible to include additional information on the GUI screens so thatadditional handler code may be generated automatically. For example, onGUI 450 of parameter editor 140, it may be possible to include a fieldfor the developer to input information as to whether the parameter valueshould be displayed to the user if the command is invoked. If such afield is included, the handler function code automatically generated byhandler code generation engine 135 will include the lines of code todisplay the parameter value. The developer would not have to add morecode to accomplish this function because it would be generatedautomatically.

[0048] Automatic code generation saves the developer time inimplementing new commands and results in a more modular form of thesoftware code for the operating system. For example, there may bemultiple developers working on implementing various command sets into anoperating system. By using the automatic code generation feature, thesedevelopers will not need to type in as many lines of code by hand forthe handler functions. In the process of setting up the commands, thehandler functions and the parameters through the visual tools (e.g., theGUIs) provided by command node editor 120, handler editor 130 andparameter editor 140, respectively, the developers are also entering allthe required information to automatically generate the handler functioncode. Thus, there is a coordination between the setting of commands,handler functions and parameters and the generation of the handlerfunction code. Additionally, since handler code generation engine 135 isgenerating the code automatically, each developer will have the samecode to accomplish the same functions within different commands.Therefore, when a developer looks at the code for a different command,the structure of the code and common functions will be exactly the same,allowing for easy troubleshooting and transportability of the code.

[0049] When a new command is entered by the developer, command structuregeneration engine 145 will add additional code to the command structureto incorporate the information added by the developer using the visualtools (e.g., the GUIs) provided by functions 110-140. Additionally,handler code generation engine 135 uses the information added by thedeveloper and the information generated by command structure generationengine 145 to automatically build the handler function code. After theprocess of FIG. 6 has been completed, a user of the system may accessthe new command that was inserted by the developer.

[0050] Referring back to FIG. 4, GUI 200 also has “−”button 202 whichmay be used to delete a command node. For example, the developer mayhighlight the command node to be deleted and then presses “−”button 202to delete the command node. When a command node is deleted, all itschild command nodes may also be deleted. For example, if the developerdesires to delete set node 260, child nodes 261-263 may also be deleted.Thus, there may be a prompt or a message given to the developer to makesure that the developer wants to delete the command node and all itschild nodes before the delete function is carried out.

[0051] GUI 200 may also be used to edit command nodes and the locationof command nodes in the command structure. For example, if the developerdesires to edit command0 node 210, the developer may highlight command0node 210 and press edit button 203. This may cause GUI 400 of commandnode editor 120 to appear to the developer so that it may be edited bythe developer. Similar to the creating of a command node, GUI 400 allowsany of the fields to be edited, including the addition, deletion andediting of parameters and handler functions. When the edits arecompleted, the developer may press apply button 442 of GUI 400 and theedits are saved for the command node. When a command node is edited,command structure generation engine 145 and handler code generationengine 135 may also be invoked to edit the command structure, thehandler function definitions, the parameter definitions and the handlerfunction code based on the changes made to the command node, parametersand handler functions by the developer. As described above, the commandstructure, the handler function definitions, the parameter definitionsand the handler function code is automatically generated based on theinformation provided by the developer and therefore may need to berevised based on any changed or additional information provided by thedeveloper. For example, referring to FIG. 9, GUI 500 has a reconcileparameter changes button 514. When a developer edits parameters in ahandler function through GUI 500, the developer may press button 514 andthese changes will be automatically reconciled in the handler functioncode by handler code generation engine 135. Those of skill in the artwill understand that in the case of the handler function code, adeveloper may write additional lines of code to incorporate any otherfunctionality in addition to the base functionality provided by handlercode generation engine 135. In this case, handler code generation engine135 may provide a function that any code that was previously added bythe developer may be transported or copied to the new handler functioncode that is generated as a result of edits to the command node by thedeveloper.

[0052] In the case of editing the location of a command node, GUI 200may be used to drag and drop a command node from location to another.For example, it may be possible to highlight command0 node 210 and dragit so that it becomes a child of command2 node 230. In this case, GUI400 may appear to the developer because some of the fields may have tobe edited due to the change of location of the command node. Similarly,the developer may copy a command node by highlighting the particularcommand node and pressing a copy button available to the developer. Thedeveloper may then paste the contents of the copied command node to anew node in a location selected on GUI 200. This would copy the contentsof an entire node to a new node which the developer may then edit.

[0053]FIG. 10 shows an alternative exemplary GUI 550 for functions120-140. GUI 550 incorporates interfaces for each of command node editor120, handler editor 130 and parameter editor 140. GUI 550 may be enteredin the same manner as GUI 400 of FIG. 7 (e.g., the developer desires toadd a new command node to command structure manifest 110). In parentfield 555, the operating system enters the name of any parent commandnodes. In the example of FIG. 10, the command node being added is achild of command0. If the command being added is a child of the rootcommand node, parent field 555 would remain blank. If the new commandnode has a grandparent, the entire branch of the command structure towhich the new command mode is a member will be displayed in parent field555. Code field 560 displays the information that has been added to thecommand. The text that is displayed is normally what the developer wouldneed to enter to create the command. However, in this case, the text isautomatically generated when the developer uses GUI 550 to build thecommand. In the example of FIG. 10, the following text is in code field560:

C=command1, HS=“help for command1”

[0054] This text indicates that the name for the command (e.g., C=) iscommand1 and the help string for the command (e.g., HS=) is “help forcommand1.” The details of how this code was generated are describedbelow.

[0055] Insert command node field 570 has a listing of information thatmay be included in the command node. This information is similar to theinformation shown in GUI 400 of FIG. 7. The developer may highlight theinformation to be added and then add the information in text field 571.For example, the developer may highlight the Name information box (e.g.,Name (C=)) and then enter the name of the command in text field 571. Tobuild the text in code field 560 shown in FIG. 10, the developer wouldenter “command1” in text field 571 and then press add button 572. Thesystem would then generate the text “C=command1” in code field 560.Similarly, the developer would then highlight the Help Stringinformation box (e.g., Help String (HS=)) and enter “help for command 1”in text field 571.

[0056] Insert parameter field 580 operates in a similar manner to insertcommand node field 570. The developer may highlight the information tobe added and then add the information in one of text fields 581 and 584.Pressing add button 582 saves the information for the parameter. Thoseskilled in the art will understand that one or both of text fields 581and 584 may also convert into a pull down menu when the type ofinformation to be added is a limited set of data. For example, whenadding the parameter type (e.g., Type (TP=)), the type of data to beadded may be limited to particular types of parameters (e.g., unsignedlong, integer, string, boolean, etc.). Therefore, text field 581 mayconvert to a pull down menu listing these types of parameters and thedeveloper may select the parameter type from the pull down menu. Insertparameter field 580 may also have name field 583 which indicates thename of the parameter currently being added. Since a command node mayhave multiple parameters, the developer may desire to see the name ofthe parameter on which work is currently being performed. Similarly,insert parameter field 580 may also have unnamed field 585 to indicatethe number of the unnamed parameter on which work is currently beingperformed.

[0057] Insert handler field 590 also operates in a similar manner toinsert command node field 570. The developer may highlight theinformation to be added and then add the information in text field 591.Pressing add button 592 saves the information for the handler function.When the developer highlights the required or optional parameterinformation box, text field 591 may convert to a pull down menu with theavailable parameters. The developer may then select the desiredparameter from this list of available parameters from the pull down menuin text field 591.

[0058] When all the desired information for the new command node iscomplete, the developer may press the submit button and the informationwill be saved and the automatic files will be generated (e.g., commandstructure, handler function definition, parameter definition, handlerfunction code) for the new command node which will be inserted intocommand structure manifest 110. GUI 550 may be considered to include allthe functionality of GUI 400, GUI 450 and GUI 500. GUI 550 may also beused to edit command nodes, parameters and handler functions.

[0059] In the preceding specification, the present invention has beendescribed with reference to specific exemplary embodiments thereof. Itwill, however, be evident that various modifications and changes may bemade thereunto without departing from the broadest spirit and scope ofthe present invention as set forth in the claims that follow. Thespecification and drawings are accordingly to be regarded in anillustrative rather than restrictive sense.

What is claimed is:
 1. A system, comprising: a code generation engineautomatically generating software code for a handler function using oneof handler function information and parameter information.
 2. The systemof claim 1, wherein the one of the handler function information and theparameter information is received via a graphical user interface.
 3. Thesystem of claim 1, further comprising: a command structure generationengine automatically generating handler function definitions andparameter definitions, wherein the handler function information includesthe handler function definitions and the parameter information includesthe parameter definitions.
 4. The system of claim 1, wherein the codegeneration engine includes a code editor adapted to permit editing ofthe automatically generated software code.
 5. The system of claim 1,wherein the code generation engine automatically edits the automaticallygenerated software code when a change is made to the one of the handlerfunction information and the parameter information.
 6. The system ofclaim 1, wherein the handler function corresponds to a command lineinterface command.
 7. A method, comprising the steps of: receivingparameter information via a graphical user interface; receiving handlerfunction information via a graphical user interface; and automaticallygenerating handler function code using the parameter information andhandler function information.
 8. The method of claim 7, furthercomprising the steps of: automatically generating parameter definitionsusing the parameter information; and automatically generating handlerfunction definitions using the handler function information.
 9. Themethod of claim 7, further comprising the step of: automatically editingthe automatically generated handler function code when one of theparameter information and the handler function information is changed.10. A system, comprising: a command graphical user interface to displaycommands in a command structure; a command node editor to edit commandsdisplayed in the command structure, wherein commands to be edited areselected on the command graphical user interface and edits are saved inthe edited commands and wherein the command node editor includes acommand editor graphical user interface on which the edits to thecommands are made; a parameter editor to edit parameters associated withthe commands, wherein the command editor graphical user interfaceincludes an interface for editing parameters and the parameters includeparameter information; a handler editor to edit handler functionsassociated with commands, wherein the command editor graphical userinterface includes an interface for editing handler functions and thehandler functions include handler function information; and a codegeneration engine automatically generating software code for the handlerfunctions using one of the handler function information and theparameter information.
 11. The system of claim 10, further comprising: acommand structure generation engine automatically generating handlerfunction definitions using the handler function information andparameter definitions using the parameter information.
 12. The system ofclaim 11, wherein the command structure generation engine automaticallygenerates code corresponding to the hierarchical command structure. 13.The system of claim 10, wherein the command structure is a hierarchicalcommand tree.
 14. The system of claim 10, wherein the editing ofparameters includes one of editing an existing parameter, adding a newparameter and deleting the existing parameter.
 15. The system of claim10, wherein the editing of handler functions includes one of editing anexisting handler function, adding a new handler function and deletingthe existing handler function.